将企业应用程序视为对外部世界事件做出反应的系统，是一种由来已久的思考方式。这种思维方式在 80 年代下半叶的结构化设计社区中确立。现在，您会在“事件驱动架构”的旗帜下听到它。在 2000 年代中期，我开始收集这类系统的一些模式，但此后一直未能将它们变成更充实的东西。尽管它们粗糙且尚未成熟，但我确实认为它们提供了一些关于事件协作本质的有用想法，引入了“事件溯源”一词，使用并行模型来表示假设的世界状态，以及如何使用协议调度器组织领域逻辑。

去年年底，我参加了与 Thoughtworks 同事们一起举办的一个研讨会，讨论“事件驱动”应用程序的本质。在过去的几年里，我们一直在构建大量使用事件的系统，它们经常受到赞扬，也经常受到谴责。我们的北美办事处组织了一次峰会，来自世界各地的 Thoughtworks 高级开发人员齐聚一堂，分享想法。

峰会最大的成果是认识到，当人们谈论“事件”时，他们实际上指的是一些截然不同的事情。因此，我们花了很多时间试图梳理出一些可能有用的模式。这篇笔记简要总结了我们确定的主要模式。

LMAX 是一个新的零售金融交易平台。因此，它必须以低延迟处理许多交易。该系统构建在 JVM 平台上，其核心是一个业务逻辑处理器，可以在单个线程上每秒处理 600 万个订单。业务逻辑处理器完全在内存中运行，使用事件溯源。业务逻辑处理器被 Disruptor 包围 - Disruptor 是一个并发组件，它实现了一个无需锁即可运行的队列网络。在设计过程中，团队得出结论，最近使用队列的高性能并发模型的方向与现代 CPU 设计根本不一致。

CQRS 代表**命令查询职责分离**。这是我第一次听到 Greg Young 描述的一种模式。其核心是，您可以使用与读取信息所用模型不同的模型来更新信息。对于某些情况，这种分离可能很有价值，但请注意，对于大多数系统而言，CQRS 会增加风险复杂性。

这是一种我遇到过几次的应用程序风格。该应用程序主要是一个报告应用程序，它为用户提供有关某事物状态的实时信息。它是一个活动应用程序，因为用户可以控制他们正在查看的内容，他们能够深入到特定区域并通常可以操作他们的显示；然而，它仍然至少主要是一个只读应用程序。

当人们启动企业应用程序时，最早的问题之一是“我们如何与数据库对话”。如今，他们可能会问一个稍微不同的问题：“我们应该使用哪种数据库 - 关系数据库还是这些 NoSQL 数据库之一？”。但还有另一个问题需要考虑：“我们应该使用数据库吗？”